home *** CD-ROM | disk | FTP | other *** search
- Path: engnews1.Eng.Sun.COM!taumet!clamage
- From: "Paul D. DeRocco" <pderocco@ix.netcom.com>
- Newsgroups: comp.std.c++
- Subject: Conflicting purposes of exception spec
- Date: 18 Feb 1996 02:14:44 GMT
- Organization: ?
- Approved: clamage@eng.sun.com (comp.std.c++)
- Message-ID: <3125C082.2946@ix.netcom.com>
- NNTP-Posting-Host: taumet.eng.sun.com
- Mime-Version: 1.0
- Content-Type: text/plain; charset=us-ascii
- Content-Transfer-Encoding: 7bit
- X-Mailer: Mozilla 2.0b6a (Win95; I)
- Content-Length: 3190
- Originator: clamage@taumet
-
- It occurs to me that exception specifications, at least empty ones,
- have two possible purposes, and that they conflict in a sense. One is
- to inform the compiler that exceptions actually won't occur, and the
- other is to trap any exceptions that the programmer didn't think would
- occur but wasn't sure about. The former is in the category of an
- optimization hint, like the "register" keyword, while the latter is a
- debugging aid, like an assertion.
-
- An empty exception specifier can be a significant aid to optimizing
- the caller of a function. If the caller has a local object whose class
- has a destructor, it needs to set up an exception context to guarantee
- that the destructor is called even if an exception is thrown. If the
- body of the function contains no function calls and no throw
- statements, then it can optimize out the exception context. In theory,
- it can also optimize it out when there are function calls, as long as
- they all have throw() in their declarations.
-
- So consider a simple function that I _know_ won't throw an exception:
-
- int sumsq(int a, int b) { return a * a + b * b; }
-
- Do I put a throw() clause on it or not? If the compiler uses throw()
- only as an optimization hint to the caller, then I most definitely
- _do_ want to use it. If, on the other hand, the compiler treats
- throw() as a command to add code to prevent any exceptions from
- propagating out of the function, then I most definitely _don't_ want
- to use it. If I guess wrong about the interpretation, I've bought
- myself nothing, and cost myself something. And unless it's spelled out
- in the language definition, I can't make _either_ choice without
- knowing that it won't ever be compiled with a compiler that was
- designed with the opposite choice in mind.
-
- When non-empty exception specifiers are present, things are a bit
- simpler, because such a construct isn't particularly useful as an
- optimization hint. When compiling the caller of such a function, an
- exception context is needed to guarantee destructor cleanup if _any_
- exception can be thrown, even if it is a limited set. About the only
- situation where a non-empty exception specifier can aid optimization
- is if a try block contains only calls to functions that can throw
- exceptions that aren't mentioned in the catch clauses. But in real
- life, one doesn't try to catch exceptions unless they can actually
- occur.
-
- This suggests that the use of an exception specifier as an assertion
- is the "correct" interpretation. But the use of an empty specifier as
- an optimization hint is potentially useful, so I propose an
- alternative. Let throw() intercept all exceptions and turn them into
- unexpected(), but use throw(void) to mean that the function really
- doesn't throw any exceptions.
-
- So what should happen if a function declared with throw(void) actually
- throws an exception? Consider it "ill-formed", and let it do whatever
- it likes, including unwinding the stack and missing destructors. This
- would certainly be a bug, but there are entire categories of functions
- that the programmer can be assured will never throw exceptions,
- including just about the entire C string library.
-
- --
-
- Ciao,
- Paul D. DeRocco
-
- [ To submit articles: Try just posting with your newsreader. If that fails,
- use mailto:std-c++@ncar.ucar.edu
- FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
- Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
- Comments? mailto:std-c++-request@ncar.ucar.edu
- ]
-